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ABSTRACT 

The integrated information system element of the 
manageaent information system concept has practical applications for 
management in the areas of both information analysis and 
decision-model building. Four basic options for achieving integration 
in operational data systems are: a default option, the coordinated 
file option, the distributed processing option, and the data base 
option. Arizona State University (ASU) has chosen a data base 
management system (DBHS) to coordinate disparate existing systems and 
eliminate extensive manual integration of data from the various 
c.ystems. However, raising a budget for the project is not a simple 
matter. Difficulties also arise in convincing the diverse elements of 
a university's bureaucratic hierarchy to cooperate on a DBMS. At ASU, 
a Data Base Review Committee, representing major administrative 
areas, has been set up to encourage effective management/technical 
interaction and inter-departmental cooperation in data base 
development. (Author/LS) 
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MANAGEMENT/TECHNICAL INTERACTION 

! 

IN INTEGRATED INFORMATION SYSTEM DEVELOPMENT 



Clarence Bagley and Don E» Gardner 



The "Integrated System Approach " 

"State of*' the art" computer-based information system development has 
come a long way toward realizing the theoretical potential described in the 
Management Information System (MIS) literature of the raid-sixties • Four or 
five years ago, the MIS raovement appeared to have lost much of its "buzz-word" 
popularity ~ which was reflected in the number of articles describing "MIS- 
fai lures" and "costly disappointments" in business and industry • Currently, 
however, there seems to be a growing number of reports of successful MIS 
implementations (complete with sophisticated built-in decision model 
capabilities) and a growing body of evidence that the MIS concept is "here 
to stay#" 

One of the elements of the MIS movement that is acquiring increased 
practical credibility is the concept of the "integrated information system*" 
Admittedly, the ideal of the "totally integrated" system remains just that — 
an ideal, but the concept appears to be gaining new adherents, and expanded 
theoretical possibilities* For example, Sprague and Watson^ recently pro- 
posed a conceptual framework for a business "decision support system" x^hich 
proposes integration of: all relevant internal and external data collection, 
manipulation and analysis; all management decision-model building activities; 
the resulting decision models themselves (at three different "levels"); and, 
through the use of a high-level corranand language, the decision/maker user 
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(see Figure !)• This represents a challenge for attempting a very high level 
of integration indeed, and one might well ask how it might be realistically 
accomplished, particularly in a college or university* 

The need for skilled decision-model builders aside, the basic require- 
ment for successful application of the concepts proposed in the Sprague/Watson 
model is achieving effective integration of the operational systems (where 
"transaction data" are captured, stored and processect) so that a viable 
"decision support data base" can be constructed* As indicated in Figure I, 
in a typical business, the four basic transaction data systems are production, 
marketing, finance and personnel; substitute "student" and "facilities" inform- 
ation systems for production and marketing, and the model applies just as well 
to a college or university* 

What are the alternatives for achieving integration in operational 
data systems? At a broad conceptual level, there appears to be four basic 
options (these almost certainly overlap in actual practice): (1) a 

default option, (2) the "coordinated file" option, (3) the "distributed 
processing" option, and (4) the "data base" option. 

The obvious "default option" is depicted in Figure 2. This is the 
situation where little or no integration exists between operational data 
systems so that the only means that exists for correlating data from different 
departments is "manual massage*" Practical experience from an administration 
point of view affirms that manual massage is "alive and well" and, to some 
degree, will undoubtedly live on forever* For example, the Office of 
Institutional Studies at Arizona State University (ASU) is currently faced 
with the prospect of considerable manual effort in bringing together faculty 
data (for cost analysis purposes) that are presently scattered among four 
basic systems: Position Control, the Academic Vice President's Faculty File, 
the Payroll Master File, and the Master Course File* It is almost impossible 



to describe to some university administrators the amount o£ manual effort 
that is sometimes required to pull together accurate, timely data from four 
separate systems which v;ere each designed v;ith a distinct purpose in 
mind* v 

Of course, the basic option for achieving integration in the data 
processing shop is the technique of ''coordinated file processing'' (see 
Figure 3)» Here, integration is accomplished through "cross-walk programming, 
the creation of "extract files" of selected data elements from operational 
systems, and other similar techniques* For example, as a possible interim 
solution to the ASU fc^culty data problem mentioned above. Administrative 
Systems and Programming personnel — without changing the basic operational 
systems in any way — may develop the necessary software to create and main- 
tain a new "personnel history file" which extracts data from all four 
operational systems* Unfortunately, data processing technicians are well 
ax^;are of the complexities and problems associated vrLth this type of 
procedure — especially inhere standardized assumptions and basic data clement 
definitions are lapking* Data Management System software (not to be confused 
with Data Base Management Systems, to be discussed later) such as Infomatics' 
MARK IV, can go a long way toward facilitating correlation of data in a 
basically non-integrated environment; however, standard "keys" for cross- 
referencing data must be present in the existing files, or added later — 
perhaps at considerable expense* Because this method of achieving system 
integration is necessarily "after the fact," there will almost always be 
deficiencies of one type or another in the results* 

A new bandwagon which offers an option for integrating with a somewhat: 
different twist is "distributed processing*" The development of economical 
intelligent teirminals, compatible minx-computer systems, key-to-disk hard- 
v/are, and specialized '^turn-key" systems has already had substantial impact 



on traditional systems design concepts* For example, a centralized keypunch 
operation was once the "rule'' for data entry at ASU. Today, keypunch machines 
have been replaced with UNIVAC key-to-disk equipment, including "distributed" 
key stations for direct input of transactions in the university purchasing 
department* Also, new equipment has been purchased for university cashiers 
which includes a built-in minicomputer (and random access storage) that will 
interface t^dth the main financial system at the central site. The implication 
is clear that, as distributed processing concepts become widespread, a new 
level of "hardware dependent" integration will be designed into specialized 
subsystems that "talk to" or "feed" one another at different levels of 
interaction (see Figure 4). 

The final option, and the one selected at ASU as the primary method of 
achieving "truly" integrated data processing on our campus, is the development 
of an integrated data base through the use of a Data Base Management System 
(DBMS)* In our case, the DBMS software being used is UNIVAC's DMS-1100; 
other commercially available DBMS packages include TOTAL, IDMS, SYSTEM 2000, , 
ADABAS and IMS 2 (for IBM users). Essentially, a DBMS package facilitates 
non-redundant, application-independent data storage with data elements linked 
together in a variety of possible hierarchical or network (chained) relation- 
ships. To oversimplify, instead of data inputs from different functional 
areas \^athin the university being fed intD physically separate tape and disk 
files, selected inputs from the various departments are funneled through 
carefully controlled maintenance procedures into a single mass storage "file" 
(s-^e Figure 5). Theoretically, at least, the data elements stored in the 
resulting data base may be linked in an infinite variety of v/ays to produce 
required reports. 

The expected advantages and potential benefits which prompted the selection 
of the DBMS approach at Arizona State University have been presented elsewhere.^ 
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Perhaps the major disadvantage of the approach is 'that it represents not 

only a technological departure from traditional data processing methods, 

but a conceptual and philosophical departure as well* From a systems 

V' 

analyst point of view, this conceptual difference has been expressed by 

one author as follows: 

"The traditional approach to data processing develop- 
ment has been the specification of a problem followed by 
its design, implementation and delivery to the user* 
This methodology implies that the problem derives programs, 
and that the programs derive the files on which the pro- 
grams operate- That is, the files of the traditional 
function or file oriented approach to data processing are 
intimately connected to the programs that operate on 
them* _ 

• • • rather than beginning with a design and 
implementation for a particular problem, data base asks 
that we develop first the data necessary to the solution 
of the problem* That is, instead of developing algorithms, 
and implementing programs to represent them, we must first 
bring cogether all of the data that is necessary for pro- 
vision of the services that will be delivered by the 3 
execution of the new application system on the data base*" 

From a management point of view (and the rest of the user community) 

the primary conceptual difficulty seems to be one of convincing people of 

the potentially over-riding benefits to be realized from maintaining the 

data base as a "shared resource*" Simply put, user departments must be 

convinced that they will benefit from replacement of their "cherished" 

(proprietary) file-oriented systems \^th a single data base system that 

can be "shared" by the community of users* 

History and Organization oE the University: Some Implications 

The organization of the typical university, historically and operationally, 
dictates against the DBMS approach. With its increasing complexity of operations 
the university has taken its place as a valid bureaucracy (many in the over 100 
million dollar class) i-rith a very distinct hierarclyof department heads, directors 
and vice presidents. This bureaucracy fragments data processing systems and 
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works against the concept of a unified approach to information handling. One 
of the reasons for this fragmentation has been a clear lack of understanding 
by the administration as to the complexity of data gathering and its validity 
in university operations. This lack of under^'tanding, coupled with the 
propensity of academia to eschew any form of cost analysis, has led to an 
organizational dichotomy when academia has hired a set of "experts" to "handle 
the business and run the shop." The university has suffered because 
report producing activities have been polarized away from the academic pro- 
gram, but have become absolutely necessary to its operation and objectives. 

Experience has shown that each office or administrative unit within the 
university develops its "fi'.e system" complete from data collection forms 
to Hollerith cards, to computer tape and disk files. Only a minority of these 
ar« designed to satisfy needs outside the originating office. 'Duplication 
becomes the style leader and standardization is highly fragmented or ignored. 
The status quo is encouraged by ill-defined data elements, "sloppy" data 
files, and a perception that planning ends at the office door. Introduced 
into this maze of self-interests, with its provincial and petty procedures, 
the DBMS approach presents a distinct educational and learning problem to 
the university community. 

In most cases, the educational process required for implementation of a 
DBMS will need to be "forced" because there is very little liklihood that a 
cooperative endeavor will evolve without a strong outside, stimulus and a 
predisposition to respond to such a stimulus. The university community is 
not known for effective self-study of its own operations. 

The establishment of an integrated data base is like many other "innovations" 
which may rise to certain heights of administrative dominance. Acceptance of 
the DBMS approach will depend on (1) a. pressing need (or at least a need that 
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is perceived as pressing), (2) the tacit support of key top mangement, (3) 
adequate or more than adequate budget and personnel or, lacking that, some 
type of "pirated" support, and (4) an entrenched operational mode. In 
these days of budget restrictions and possible cutbacks, the outlook for 
potentially expensive new approaches has been reduced — yet the same 
monetary restrictions may force an evaluation of alternative methods^ 

Proponents of institutional research, learning resource laboratories, 
the "university without walls" concept, and MIS have all used, with varying 
degrees of success, the procedures outlined above* The business and 
financial departments of the university used such procedures thirty years 
ago to firmly entrench themselves. Their celebrated cause was "financial 
accounting by the state," an imposed bureaucratic inconvenience that academia 
quickly turned over to business "professionals*" To the extent that the four 
conditions are met, the DBMS will be successful. We may ask, what are the 
chances? Is it possible to introduce a drastically different set of standards 
into a well-entrenched bureaucracy? 

Most often the university reacts only to what has been called "macro- 
environment press"; that is, to the demands of those outside agencies which 
require data or information. The state or federal agency that makes the 
request is perceived as important depending upon the "power over the budget" 
held by that agency. Correlated with the perceived outside need is the local 
perception of vested interests; that is, the old admonition of "let us band 
together or we will hang separately," a prevailing concept among m.any vice_ 
presidents. 

Basic then to DBMS is a need, either real or perceived, which has been 
assigned to or recognized by top management. Top management itself will 



contain- very few people -capable o£ or willing to direct implementation of 
the DBMS approach* The "grab for power" \n,ll be perceived as exactly that — 
with a rationale for the common good of the university running a poor second. 
Looking at the university as a single, comprehensive entity is not a common 
outlook for top management. 

Simply put, top management is either "too busy" or not sufficiently 
technically oriented to guide DBMS implementation. Their task is to perceive 
in a political reality what they do best — service the demands for information 
about what is going on at the university while keeping the till full and money 
floi^ng. Top management's position is not really to accentuate the truth, 
but to maintain that which is defensible and that which allows the opponent 
little opportunity to know exactly what is happening. The charisma of a 
president was, and is, indeed a powerful factor in sftlling higher education. 
Boards, legislative groups and NCIIEMS are applying pressures that are changing 
the role of the president and the "higher education" ^he must now "sell" is 
changing continually to fit different standards. Data and information are 
"getting into the game" and top management can no longer depend upon the ability 
of any single person (no matter how prominent) to sell the story. "Evaluation" 
is no longer accomplished in a day testifying before the legislature, but now^ 
is year long and in excruciating detail. The demands are here and becoming 
stronger each year. Those who wait until that last minute to start their 
integrated information system will find themselves at a severe disadvantage 
in the informati-on-game. 
Budgetary and Organizational Impacts 

The impact of a DBMS approach may be likened to the impact of computer 
systems in general, when assessed for potential budget and organizational change < 
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An integrated data base is potentially expensive, and budget conscious 
.administrators may not appreciate the financial drain thaC might occur* 
However, the alternative is also costly — a lack of information* Worse, 
in a large university, the intangible drain on personnel and their time is 
almost incalculable where extensive, unnecessary clerical tasks are required 
to integrate information from existing systems. Ftirthermcre, many administrators 
would rather incur the expense of hiring a larger office staff than cooperate 
in effocts directed toward creating more efficient integrated systems. Un- 
fortunately, power and authority are derived from the larger staff and the 
quantity of routine procedures performed. 

Granted, the scope of administrative responsibility has increased during 
the past ten years. Budgets, Affirmative Action, EEO and "sponsored research'* 
have individually created their own problems of increased work load; however, 
the principal problem is that they have gro^^m in piecemeal fashion, again 
reflecting the organizational history of the university! Simply stated, 
impact on the institutional budget will most probably be acknowledged in 
typical academic fashion; that is, the new approach to information processing 
must compete against the established bureaucracy for necessary resources* 
"All new programs must compete against operational sacred cows," is another 
\/ay of stating this problem that DBMS implementers must face. 

An operational DBMS may only achieve functional powet as a result of 
budgetary attacks on the university and the need to provide integrated 
information to meet those attacks. Organizational ly, the establishment " of 
the integrated data base will be dic^ated at the highest level as a function 
of power and authority. Clearly, the vice presidents (normally in direct 
competition with one another) should champion DBMS. Organizationally, one 
of these political identities — or the president himself — must carry the 
fight. 



Yet the most important planning and operational activities lie with middle 
management* This group will have the necessary knowledge — in sufficient 
detail to validate the DBMS-based system. While they lack the influence 
of "single coordination" (a reasonable disadvantage when vjorking with the 
various offices and units on campus) there is no other group with the knowledge 
and time to provide adequate support for the DBMS effort* After the need for 
information is perceived and top management provides for its establishment, 
the actual job lies with middle management* 

We might then ask, what might motivate the middlo management group in a 
specific university environment to assume the responsibilities associated with 
DBMS implementation? Technically, the hardware and soCtware are available* 
The real crux of the problem lies in the conflict of UMS-based integration 
with the traditional university — its provincial, archaic approaches, sheer 
inertia, and hidden confusions can only be overcome in the power struggle 
through middle management support* Proponents of the integrated system must 
be in tune with the "bureaucratic concerns;" of middle managers and successfully 
demonstrate how the data base can help alleviate those concerns* At any rate, 
there is no other viable resource — top management has generally failed (with 
some exceptions) to show the necessary leadership in this area. 

In view of the above, steps toward integrated data base implementation 
will probably involve middle management pushing top management for acceptance • 
The perception of those in middle management and their education will play an 
important part in the DBM^ effort. Assuming a need is recognized ^by top 
management, and is eventually expressed in a policy of action, there are 
several other problems to be overcome* One is that of providing an "admin- 
istrative vehicle" for successful planning and implemenfati on* Unfortunately, 
in a large university there are many persons who are -apparent "strangers 
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to each other" in middle management - aware only f leetingly of the responsi- 
bilities of others. Even those having a clear concept of what they need and 
have, can be totally ignorant of the complexity and inter-departmental 
implfcations of an integrated system effort. 

Another requirement is that a designated 'team of experts xvith a clearly 
specific chairman or leader should be appointed to help with DBMS implementation. 
Thfese may or may not b^ from middle management, but would necessarily include 
systems personnel. The critical educational problem here surrounds the principle 
of "involvement." Educational methods should be based on the concept that there 
a single "whole" which is greater than the "parts." While there may need to be a 
administrative "Czar" to determine policy and "who is going to do what," the 
essential concept must be established that a DBMS-based integrated system is a 
university concept and not charged to any single office or department. 
The "Data Base Review Comniittee" Conce pt? Background 

Genernlly, in traditional "f iie-oriented'' system development, the 
systems analyst can focus almost all of his design efforts toward satisfying 
the needs of a "single department" client/user. In contrast, in a DBMS- 
based integrared environment, while a project leader may still be working 
toward the goal of satisfying a' particular user^department, his efforts will 
be much more constrained by "total system" requirements. 

\lhat this means in terms of technical interaction, is that the anaLyst-/ 

O 

project leader must now interface vjith a new element within his own shop, 
i.e., the data base administrator and other members of • th^e "data base support 
group." In terms of management /tehcnical interaction, no longer can the analyst 
content himself that the requirements for a good system design will be met if 
the primary user department head "approves." That department head (whether it 
be the Registrar, Comptroller, Director of Financial Aids, etc.) will no longer 
be responsible for a data processing system that functions essentially in 



isolation from all other systems on campus, but will "manage** a component sub- 
system of the larger, integrated framework* Therefore, the analyst/project 
leader must be much more aware of the data processing requirements of the 
"managers" (department heads, deans, etc#) in^other areas — and how they 
relate to his project than has traditionally been the case# 

Some persons will argue that good systems analysts have always considered 
interpersonal interaction outside of the narrow confines of their specific 
"client departraent ," a necessary prerequisite to creating a "good" system 
design. Also, they will argue that university department heads and directors 
must necessarily viexvr their area of responsibility as just another component 
of the larger college or university system. In theory, and in certain specific 
circumstances, this has undoubtedly been true.' Judging from personal experience 
and the comments of professional collegues, a much more typical situation is 
where functional departments exist as "little empires" in continual competition 
for budget dollars via the politics of "good turfmanship." Unfortunately, 
if this is the case, there will be little motivation for creating efficient 
integrated data processing systems so the proliferation of proprietary 
"file-oriented" systems continues. On the other hand, in the DBMS-based 
integrated system environment, inter-departmental interaction is a critical 
requirement for success; once this fact is recognized and accepted, it can 
become a primary motivating force in and of itself. 

Today it is becoming more and more the case that management information 
requirements of the central administration (whether at the vice-presidential, 
presidential, chancellor, or state-wide level) demand effective integration 
of operational data systems. If the DBMS-approach to integration has been 
selected, what type of mechanisms might be created to insure that the necessary 
management/technical interaction and inter-departmental cooperation will occur? 
One .approach is the creation of a top-level data base steering committee with 
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real authority to direct and control system development within the framework 
of the integrated approach. In business applications a common recommendation 
is that the data base administrator have absolute authority on matters con- 
cerning the data base, e.g., data element definitions, approval of system 
designs in all areas of interface, etc. Another approach is to involve 
representatives of all departments in development of a total system desi^ 
beiore implementation of any particular subsystem can begin. One or another 
of these mechanisms may be the primary ingredient of an approach that incorporates 
all three; certainly other techniques may be more particularly suited to 
specific situations and circumstances. 

At Arizona State University, conditions have not been favorable to the 
organization of a powerful 'Mata base steering committee." Furthermore, the 
role of the "data base administrator" has been conceptualized more as one of 
technical design and control, as opposed to policy-oriented decision making* 
The concept of true "total system design" \^as rejected as too costly, and 
self-defeating in the long run because of the ever-^changing nature of the data 
processing requirements of the various university departments. A word of 
explanation is in order on this last point because some type of over-all 
framework or design structure must be developed to guide data base development. 
Hot^ever, a theoretical "schema" of a data base for the university can be 
developed without excessive cost, which still should be adequate to establish 
the parameters needed to guide project implementation. ^ 
Data Base Review Committee: Or$>ani2ation and Structure 

The principal mechanism selected to encourage effective management/ 
technical interaction and inter-departmental cooperation in data base develop- 
ment at ASU has been a twelve-man "Data Base Review Committee" (DfiRC). The 
DBRC is comprised o£ representatives from the major administrative areas of 
the university (both central administration and the academic colleges). 

-13- 



-Individuals uevQ selected with a "functional awareness" of university 
infonnation needs at various levels and for various purposes • The original 
roster included the following: the Director of Admissions; Assistant Director 
of Institutional Studies; an Assistant Coraptrollcr; the Director of Payroll; 
Administrative Assistants to the Deans of the Colleges of Engineering, Business, 
Liberal Arts, and Graduate College; the Assistant Dean of the College of Fine 
Arts; Assistant Director of Financial Aids; Assistant Director of Personnel; 
and, the Assistant Registrar* Ex-officio members include the Coordinator of 
Information Systems (Chairman), the Director of Administrative Systems and 
Programming, and the Director of Computing Systems and Operations • 

In terms of defined "roles and purposes" the committee is intended as 
a review board for monitoring the evolution of the data base, and as an "appeals" 
mechanism for arbitrating disputes that arise in the development of the university 
integrated system* The DBRC is divided into four "working sub-committees": 
(1) Data Element Dictionary/Data Definition Sub-Committee, (2) Input/Output 
Constraints Sub-Committee , (3) Data Base Standards and Controls, and (4) 
Communications/Interface Sub-Committee* Specific procedures that have been 
adopted include the following (see Figure 6): 

(a) In every project, most of the details of the "System Design" 
will be worked out by the Project Team as it interacts with 
users and the Data Base Support Group. However, problems 
and issues that arise which cannot be resolved by the 
Project Team or which have implications extending beyond 
the scope of the project in question, will be forwarded 

to the appropriate DBRC Sub-Committee through the DBRC 
chaiman* 

(b) The DBRC Sub-Committee working on a particular problem 

x^rill formulate recommendations for presentation to the committee 

ERJC 



as a whole. 

(c) In most cases, it is hoped that the efforts of the sub- 
committees I'dll result in recommendations that are, by 
nature, acceptable to everyone concerned • Where this is not 
the case, it may be necessary to fon>rard the recommendation 
to an appropriate "higher authority" in the university 
administration for resolution • 

(d) Since the data element dictionary represents a university 
resource irrespective of the particular projects under 
development, ALL proposed additions, changes or deletions 
must be reviewed by the Data Element Dictionary/Definition 
Sub-Committee and Con^arded (with recommendations) to the 
Data Base Review Committee. In this way, the capability 

of the Data Base to satisfy the widely divergent information 
needs of the university community will be insured. 

Thus far, the ASU committee has received briefings from the Coordinator 
of Information Systems, Data Base Administrator, and the leader of the "Payroll/ 
Position Control" development project. Also, the four sub-committees have 
met with systems' personnel to discuss potential probelm arear* and means for 
resolution. Members of the DBRC are currently reviewing selected items from 
the data element dictionary, and have expressed continued interest in the 
progress of the integrated system effort. » ^ ^ 

Although it is still too early to determine if the "Data Base Review 
Committee" concept will be ultimately successful in realizing the goals and 
purposes outlined above, the initial indication is favorable. If nothing 
else, there has been a noticeable increase in enthusiast! among university 
personnel for the integrated system project, and an apparent heightened 
awareness of the true meaning of "data base." Managers and technicians alike 
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arc coming to realize more and more that DBMS-based integrated system develop- 
ment is something quite different in application than traditional "file- 
oriented" data processing. ^ 
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